home *** CD-ROM | disk | FTP | other *** search
/ Mac Power 1997 December / MACPOWER-1997-12.ISO.7z / MACPOWER-1997-12.ISO / AMUG / PROGRAMMING / Raven 1.2.sit / Raven 1.2 / Documents / FAQs / Why did I write Raven? < prev    next >
Text File  |  1997-04-12  |  4KB  |  80 lines
  1. > I've downloaded Raven and had a short look at it. Now, I'm wondering why
  2. > you wrote an entirely new framework. Does it do anything that
  3. > PowerPlant, say, doesn't do, or doesn't do as good? OTOH, I didn't see
  4. > support for the AppleEvent Object Model. Did I overlook it?).
  5.  
  6. I wrote Raven because I was frustrated with the existing application frameworks. PowerPlant has 
  7. some nice ideas but it does a poor job abstracting the toolbox, has gaps in functionality, and 
  8. has lots and lots of serious implementation problems. For example, take a look at LFile:
  9.  
  10. * The interface is written using FSSpec's. Raven's file class uses TFileSpec's and TFolderSpec's. 
  11. By using a class Raven is able to provide a nice way to get information about the file or folder 
  12. and, even more important, these classes can be relatively easily ported to a path based file 
  13. system like Rhapsody.
  14.  
  15. * LFile is missing some very basic functionality (eg getting/setting the data fork length and 
  16. seeking). This makes the class harder to use and again hampers portability because your code 
  17. winds up talking to the toolbox instead of an object.
  18.  
  19. * The LFile implementation is full of problems:
  20.    - The dtor doesn't trap exceptions so your program may abort when unwinding the stack.
  21.    - MakeAlias ignores any errors.
  22.    - ReadDataFork has a memory leak if an exception is thrown by SetFPos or FSRead. (And this 
  23.      leak is the size of the file so it could be huge!)
  24.    - WriteDataFork ignores errors from SetEOF.
  25.    - None of the methods do *any* validation of the arguments.
  26.  
  27. Unfortunately these sorts of problems are present throughout PowerPlant. On the other hand, 
  28. MacApp does not have these problems. The only real problem with MacApp is that it was ported 
  29. from Object Pascal. This means it lacks the very nice mix and match style made possible with 
  30. multiple inheritance and lacked a lot of the things you'd expect in a C++ framework. (However 
  31. in the year that I've been working on Raven Apple has made great progress on turning MacApp 
  32. into a real C++ framework).
  33.  
  34. Raven does have a lot of stuff missing from PowerPlant. Here's a sample:
  35.  
  36. * Convenience classes like TPoint, TRect, TRegion, TRGBColor, and THandle. You can get by 
  37. without this sort of thing but they make the code much easier to write and to read.
  38.  
  39. * Support for animated busy cursors.
  40.  
  41. * A templatized broadcaster/listener mechanism. (Almost all the code is in non-template base 
  42. classes so the template bloat is tiny).
  43.  
  44. * A rich set of debugging macros, a framework for unit testing, and a powerful debug menu.
  45.  
  46. * A version of operator new that can use either a rewritten version of MetroWerk's fast new or 
  47. OpenDoc's BestFitHeap. The custom new provides all of DebugNew's checks and more (for example 
  48. you don't have to use NEW and when you do get a leak you get a stack crawl instead of the file 
  49. and line number).
  50.  
  51. * A nice set of sound classes.
  52.  
  53. * Flexible 2D graphing classes.
  54.  
  55. * Lots of classes to ease dealing with the file manager.
  56.  
  57. * Command objects (like MacApp's).
  58.  
  59. * Multi-level undo/redo.
  60.  
  61. * Context sensitive menus.
  62.  
  63. * More flexible event handling.
  64.  
  65. * Uses standard classes like string and STL instead of hand rolled equivalents.
  66.  
  67. * Uses the standard exception classes.
  68.  
  69. * Mouse tracker objects (like MacApp's). 
  70.  
  71. * The pane classes and the view editor fully support balloon help.
  72.  
  73. * A better architecture, better class design, and a more robust implementation.
  74.  
  75. Note that the bulk of the bottom two layers of Raven can be used with PowerPlant. 
  76.  
  77. However Raven is still missing some important things. I think the biggest are scripting support, 
  78. printing, and the weak support for custom pane types in the view editor.
  79.  
  80.